1. Field of the Invention
The present invention generally relates to data processing and more particularly to applying display profiles to queries.
2. Description of the Related Art
Databases are computerized information storage and retrieval systems. A relational database management system is a computer database management system (DBMS) that uses relational techniques for storing and retrieving data. The most prevalent type of database is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.
Regardless of the particular architecture, in a DBMS, a requesting entity (e.g., an application or the operating system) demands access to a specified database by issuing a database access request. Such requests may include, for instance, simple catalog lookup requests or transactions and combinations of transactions that operate to read, change and add specified records in the database. These requests are made using high-level query languages such as the Structured Query Language (SQL) and application programming interfaces (API's) such as Java® Database Connectivity (JDBC). The term “query” denominates a set of commands for retrieving data from a stored database. Queries take the form of a command language, such as SQL, that lets programmers and programs select, insert, update, find out the location of data, and so forth.
Unfortunately, generating queries using SQL may require a detailed understanding of the possibly complex physical layout of the underlying database and interpretation of cryptic field names. For some applications, to facilitate the query building process, an abstraction model may be utilized that, in effect, hides some of the complexities of the underlying database physical layout from users. The abstraction model may include logical fields with recognizable names that map to corresponding physical fields of the underlying database. “Abstract” queries may be generated containing conditions based on the logical fields. Upon issuance, the logical fields of an abstract query may be mapped to corresponding physical fields to create a physical or “concrete” query (e.g., an SQL query). For some applications, abstract queries may be saved, allowing subsequent users to reuse the saved abstract queries without having to generate their own. The concepts of data abstraction and abstract queries are described in detail in the commonly owned, co-pending application Ser. No. 10/083,075, entitled “Improved Application Portability And Extensibility Through Database Schema And Query Abstraction,” filed Feb. 26, 2002, herein incorporated by reference in its entirety.
While abstraction models and abstract queries make it easier and more efficient for users to access data within a database, there are situations when users want to alter the scope of the abstract queries and further process the queries' result sets without having to modify the syntax of the queries or create new abstract queries. Altering the scope of abstract queries may include, for example, considering additional query conditions directed to expanding a result set, restrict the result set or even calling existing data processing functions to manipulate data within the result set. Unfortunately, the infrastructure facilitating the abstraction model may not be flexible enough to allow for the further use of existing abstract queries and their result sets for such purposes without modifying the syntax of the original abstract queries. One alternative is to create a completely new abstract query, which may be based on combining the syntax of the existing abstract query with the syntax of additional query conditions directed to altering the result set as required by the user. There may be instances where a particular group of query conditions may need to be applied to numerous abstract queries, necessitating the creation of many new abstract queries comprising identical syntax representing query conditions.
Those skilled in the art will acknowledge that the process described above is inefficient, time consuming and wasteful of resources due to redundancies. Therefore, what is needed is a solution that allows for the ability to use previously defined abstract queries (and their corresponding result sets) by allowing for the application of additional query conditions to these base queries. Further, the group of additional query conditions should be packaged in a module and presented in abstract form so that it is convenient for the collection of additional query conditions to be selected for application to other base queries, as required by the user. In other words, the modules comprising additional query components should be capable of being applied to multiple abstract queries.